Skip to main content

Disable Root SSH Login

Disabling direct SSH login for the root account forces administrators to authenticate as an unprivileged user first and then elevate privileges with sudo. This reduces the impact of brute-force attempts, improves auditability, and lowers the chance of catastrophic mistakes during routine operations.

Background and history​

Early Unix administration commonly relied on direct root logins for convenience. As internet-exposed servers became standard, root became the most targeted username for automated attacks. OpenSSH introduced configuration controls such as PermitRootLogin to limit or disable root authentication, and modern hardening baselines typically require disabling direct root SSH access.

Adoption and where it’s commonly used​

Disabling root SSH login is common in:

  • VPS and cloud servers exposed to the internet
  • Production Linux fleets managed by multiple administrators
  • Compliance-oriented environments requiring stronger access controls and audit trails
  • WordPress and web servers where SSH is frequently targeted

Maintained by

  • Maintained by the OpenSSH project community (via the OpenSSH server).

Best when to use​

  • Servers are reachable from the internet and SSH is exposed.
  • Multiple admins manage the same host and need clear accountability.
  • You want to reduce brute-force value of the root username.
  • You already have at least one non-root account with sudo access.

Not suitable when​

  • The environment requires direct root logins by policy and you cannot change workflows.
  • There is no reliable out-of-band recovery access (cloud console/serial/KVM) and you are not confident about the current SSH configuration.
  • Automation depends on root SSH and cannot be updated to use a non-root user + sudo.

Compatibility notes​

  • OpenSSH server configuration is usually in /etc/ssh/sshd_config. Many modern distributions also support drop-in files in /etc/ssh/sshd_config.d/*.conf.

  • Service name differs by distro:

    • Debian/Ubuntu commonly use ssh
    • RHEL/Fedora/Rocky/AlmaLinux commonly use sshd

  • PermitRootLogin values vary by OpenSSH version:

    • no disables all root SSH logins
    • prohibit-password (or legacy without-password) allows only key-based root logins

  • Cloud images may already disable root login by default.

Lockout risk

Do not terminate your current SSH session while changing SSH settings. Always keep one active session open, validate configuration syntax before reloading, and confirm you can log in as a non-root sudo user in a second session.

How it works​

OpenSSH server (sshd) evaluates authentication rules from its configuration. When PermitRootLogin no is set, sshd rejects login attempts for the root account before authentication succeeds, regardless of password or key configuration.

Prefer a drop-in config file (when supported) so system updates do not overwrite your changes.

Step 1: Confirm a non-root sudo user exists​

Safe checks (read-only):

whoami
id
sudo -n true 2>/dev/null && echo "sudo: OK (non-interactive)" || echo "sudo: requires password or not configured"

List sudo group membership (common patterns):

getent group sudo 2>/dev/null || true
getent group wheel 2>/dev/null || true

If you do not have a non-root sudo user, create one before disabling root SSH login.

Do this first

Disabling root SSH access without a working sudo-capable account can make administrative recovery difficult without console access.

Step 2: Check the current effective root login policy​

Inspect configured values:

sudo grep -R --line-number -E '^\s*PermitRootLogin\s+' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null || true

Check the effective runtime configuration (authoritative for what sshd will use):

sudo sshd -T | grep -i '^permitrootlogin'

Apply the change​

Create a drop-in file:

sudo install -d -m 0755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/10-disable-root-login.conf >/dev/null <<'EOF'
PermitRootLogin no
EOF

Validate SSH configuration syntax:

sudo sshd -t

Reload SSH safely (reload is preferred over restart when possible):

sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

Option B: Allow root by SSH keys only (less strict)​

This is sometimes used temporarily during migrations, but it still keeps root as a high-value target. Prefer Option A unless you have a specific operational requirement.

sudo install -d -m 0755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/10-root-keys-only.conf >/dev/null <<'EOF'
PermitRootLogin prohibit-password
EOF

sudo sshd -t
sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd
Value naming

Some older OpenSSH versions use without-password for the same meaning as prohibit-password. Use the OpenSSH manual pages for your installed version if unsure, and confirm effective settings with sshd -T.

Verify the result​

Confirm effective setting​

sudo sshd -T | grep -i '^permitrootlogin'

Expected for full disable:

permitrootlogin no

Test in a second SSH session​

Test non-root access:

ssh <your-user>@<server>

Then test root access should fail:

ssh root@<server>

Keep your original session open until both tests succeed.

Common operational patterns​

Hardening baseline for daily admin work​

Combine disabling root SSH login with these compatible controls:

  • Use SSH keys for admin users (avoid password-based SSH where possible).
  • Ensure the admin user is in sudo/wheel and can elevate privileges.
  • Restrict SSH access at the firewall to trusted IPs where feasible.
  • Use AllowUsers or AllowGroups to restrict which accounts can log in.

Example (restrict SSH to specific users):

# In an appropriate sshd config drop-in:
AllowUsers admin ops

Validate and reload after changes:

sudo sshd -t
sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd
SSH restrictions can lock out automation

If you use deployment keys or automation accounts, include them in AllowUsers/AllowGroups before reloading.

Troubleshooting​

Reload fails or SSH configuration is invalid​

Symptoms:

  • sshd -t returns an error
  • systemctl reload sshd fails

Fix:

  1. Revert or edit the last change.
  2. Re-test syntax.
  3. Reload again.

Safe steps:

sudo sshd -t
sudo journalctl -u ssh -n 200 --no-pager 2>/dev/null || true
sudo journalctl -u sshd -n 200 --no-pager 2>/dev/null || true

Root can still log in after setting PermitRootLogin no​

Likely causes:

  • Multiple config files override the setting
  • Drop-in file order precedence issues
  • You reloaded a different SSH service name than expected

Diagnosis:

sudo sshd -T | grep -i '^permitrootlogin'
sudo grep -R --line-number -E '^\s*PermitRootLogin\s+' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null || true
systemctl status ssh 2>/dev/null || true
systemctl status sshd 2>/dev/null || true

Fix:

  • Ensure a single intended setting is present in the effective configuration (sshd -T output).
  • Adjust drop-in filename ordering if needed (lower number files load earlier; later files can override earlier ones).

You locked yourself out​

Recovery options depend on environment:

  • Cloud/VPS console or serial access: log in via console, revert SSH config, validate with sshd -t, reload.
  • Out-of-band management (KVM/IPMI): same approach.
  • No console access: recovery may require provider intervention or rebuilding.

Console recovery workflow:

# From console session
sudo rm -f /etc/ssh/sshd_config.d/10-disable-root-login.conf 2>/dev/null || true
sudo nano /etc/ssh/sshd_config  # or fix the drop-in file
sudo sshd -t
sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

Security notes​

  • Disabling root SSH login reduces attack surface, but does not replace:

    • Strong SSH key management
    • Least-privilege sudo policies
    • Network-level access controls (security groups/firewalls)
    • Monitoring and alerting for repeated failures (for example, Fail2Ban)

  • Prefer short-lived admin access paths and strong authentication:

    • Disable password auth where feasible
    • Use key-based auth and protected private keys
    • Consider multi-factor authentication solutions where supported in your environment

Quick reference​

Configuration values​

SettingEffect
----
PermitRootLogin noDisables all root SSH logins
PermitRootLogin prohibit-passwordAllows root only via public key authentication
PermitRootLogin yesAllows root SSH login (not recommended for internet-exposed hosts)

Safe command sequence​

# 1) Confirm current effective state
sudo sshd -T | grep -i '^permitrootlogin'

# 2) Apply (drop-in recommended)
sudo tee /etc/ssh/sshd_config.d/10-disable-root-login.conf >/dev/null <<'EOF'
PermitRootLogin no
EOF

# 3) Validate
sudo sshd -t

# 4) Reload (service name varies)
sudo systemctl reload ssh 2>/dev/null || sudo systemctl reload sshd

# 5) Confirm effective config again
sudo sshd -T | grep -i '^permitrootlogin'
Placeholder

Replace this note with environment-specific standards such as approved admin usernames, required SSH options, and your organization’s recovery procedures.